Closed Bug 105547 Opened 23 years ago Closed 19 years ago

Windows open in new window instead of tabs (target=<nonexistant_frame>) (_blank)

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 172962

People

(Reporter: mythdraug, Assigned: jag+mozilla)

References

(Blocks 2 open bugs)

Details

(Keywords: helpwanted, Whiteboard: [adt3][Hixie-P0][parity-opera])

Attachments

(3 files, 3 obsolete files)

patch: remove the pref for now
1.54 KB, patch
bryner
: review+
bugs
: superreview+
asa
: approval+
Details | Diff | Splinter Review
new diff -u
5.07 KB, patch
Details | Diff | Splinter Review
testcase for target="_blank"
182 bytes, text/html
Details 
Despite setting  
pref("browser.tabs.opentabfor.windowopen", true)
windows open in new browser rather than tab.

Build: 2001101803 Win32
how is the new window being opened?
..and what is the exact User Agent string in Help->About Mozilla?
What happens if you key in ctrl+t ?
bz: I noticed on an https: link at Schwab.  I believe the window
  was opened by JavaScript.  The same behavior can be found at 

R.K.Aa:  Mozilla 0.9.5+  Mozilla/5.0 (Windows; U; Windows 
  NT 5.0; en-US;rv:0.9.5+) Gecko/20011018
  ctrl-t opens a new tab.  Middleclicked links open new tabs.
  URLbar opens new tabs.  Bookmarks load in current tab (even
  with browser.tabs.opentabfor.bookmarks set to true).
that link with similar behavior is
http://www.cnn.com/interactive/#av  click "Play video"
did some testing.  is this not implemented yet?

In any case, confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It is not implemented yet.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
Ok.  No rush for me.  Just saw the pref and tried it.
another, slightly different, example url is promise.com, which has <base
target="_parent"> in the top nav frame and uses <a href="ATARaid/"
target="_blank"> for the links.

Also i suggest os/platform as all/all for searching/filtering purposes.
OS: Windows 2000 → All
Hardware: PC → All
Seeing this too.
Was hoping I could get yahoo mail to open links in a new tab... no such luck :-\
Bug 103843 sounds similar to this.
Hi ALL
Probably wrong bug, but can't find one on closing tabs.
Build ID 2001 11 07 02 Trunk Win Zip
The right click menu of close this tab- close all other tabs
is broken.
Steps:
Have two or more window tabs open.
Do right click on an open tab.
Select close other (all) tab.

Result: The last tab that was opened stays open.

Expected result is that the active tab recieving the
right click will stay open and the other or others that
were chosen  would close.
You're right, this is the wrong bug since the problem you're reporting is
totally unrelated to this.

If there's not a bug for the problem, please open a new one.
*** Bug 109470 has been marked as a duplicate of this bug. ***
*** Bug 103823 has been marked as a duplicate of this bug. ***
*** Bug 105753 has been marked as a duplicate of this bug. ***
Noting cause in summary.

FYI: The HTML spec states frame names begining with _ are RESERVED, so pages
using "_new" which is common are invalid. The reserved names assigned are _top,
_parent, _self (the default), and _blank. IE5 uses _search for its search pane.

So I suppose in quirks, anything other then top/parent/self should open in a new
tab, and in standard mode, blank opens in a new tab, and unknown reserved values
open in the CURRENT window (the default), not a new window. I suspect this might
not be the case, haven't checked yet.
Summary: Windows open in new window instead of tabs... → Windows open in new window instead of tabs (target=<nonexsistant_frame>)
*** Bug 110893 has been marked as a duplicate of this bug. ***
*** Bug 111410 has been marked as a duplicate of this bug. ***
This is working in MultiZilla for months now, so why don't you use some of the
MultiZilla code to fix this bug? Other people seems already to have copied other
MultiZilla code so why wait with this bug?
I'd like to see one additional change/enhancement.  The Galeon browser also
supports tabs.  In Galeon, every tab has got a small "cross" which you can click
to close this tab.  The advantage is, that you can view one tab and close
another, invisible tab.

This should be added.
That would be bug 108938, which I quite like.

Workaround is rightclick-c.
QA Contact: blakeross → sairuh
*** Bug 112354 has been marked as a duplicate of this bug. ***
*** Bug 112721 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 113132 has been marked as a duplicate of this bug. ***
*** Bug 113133 has been marked as a duplicate of this bug. ***
*** Bug 116203 has been marked as a duplicate of this bug. ***
Is this a metabug for prefs controlling whether new opens in tab or new window?
I have unchecked open windows by themselves in prefs, but Javascript created
popups continue to popup. e.g., any of the press releases at upper right of
http://www.mazdausa.com/autoshow/detroit/no_flash.asp. I never want anything
besides me to open a new window. Never. Ever. No exceptions.

2002010817. OS/2.
The JavaScript pref mentioned only blocks window.open during page loading and
unloading. It does not block new windows across the board.

Once this bug is fixed, will JavaScript window.open create a new tab? Or is
there another bug about that?
This bug has nothing to do with javascript window.open. I know of no plans to
force javascript windows into tabs, as they are usually size dependent and
usually meant as modal-type things. You wouldn't even notice them if they loaded
a tab in the background.

Feel free to discuss doing such a thing in the newsgroups, though.

For people waiting on this bug to be fixed, consider using this hidden pref in
the meantime. It will make links targeted to new windows open in the current
instead. Put this in the file prefs.js in your profile directory:

user_pref("browser.target_new_blocked", true);

Hyatt, this should also affect mozilla -remote openurl(foo, new-window) on UNIX
when it's implemented.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
If the user asks for "windows opened by web pages" to open in tabs, and a 
window.open does not specify a window size, it should open in a tab.  I'm not 
sure what should happen if the window.open specifies a window size.
Several of my bookmarklets, such as "Open Selected Links", use window.open 
(without specifying size or window features).  One user e-mailed me asking how 
to make it open new tabs instead of new windows, and I had to point him to this 
bug.
"windows opened by web pages" should mean windows opened by web pages, not some
windows opened by web pages. Whether window.open specifies a window size should
be irrelevant. I never want anything besides me to open a new window. Never.
Ever. No exceptions. This is my PC, not the webmaster's.
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
-> 1.2
Target Milestone: mozilla0.9.9 → mozilla1.2
Let's get the UI out of there, then.
indeed --i've filed http://bugscape.mcom.com/show_bug.cgi?id=11877 for the time
being. depending on the responses there, might just move it over to bugzilla...
we shall see.
Keywords: useless-UI
*** Bug 121617 has been marked as a duplicate of this bug. ***
*** Bug 122515 has been marked as a duplicate of this bug. ***
Works even for target="new"
*** Bug 125232 has been marked as a duplicate of this bug. ***
nsbeta1+ per ADT triage team, fix or remove pref UI for this feature, whichever
is easier.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla1.2 → mozilla1.0
Re comments 11, 28, 29 and 31...

It seems to me that this bug is about HTML, not JavaScript. Navneet is right,
the discussion of new tabs vs. new windows with JS is going on in Bug 103843
(that bug started out as concerning both HTML and JS, but the discussion has
become almost entirely JS-oriented). So, I propose that the scope of this bug be
limited to HTML, and let Bug 103843 worry about JS, because the uses of
target="_blank" and window.open() are entirely different beasts. Maybe that way
we can get at least one of the two functionalities quicker.
No, these are not "entirely different beasts" as you suggest, because they both are supposed to 
open in new tabs when this pref is set. It is completely irrelevant what mechanism is used to open 
the new window in regards to whether it should be a tab or a window. If the user specifies "New 
windows should open in tabs", they should open in tabs, regardless of how the web site designer 
wrote it.
You are correct, these bugs are closely related.  But I suggest they continue to
be tracked as seperate bugs for two reasons:

1.  They may have seperate fixes.  One issue may be fixed before the other.  If
so, seperate bugs make it easier to track progress and to make it clear how to
reproduce the problem.  If it turns out the fix is the same, then we simply
close two bugs with one fix.

2.  It is reasonable to argume that, from a user perspective, a window is a
window and they should all be redirected to tabs.  But it is not universally
accepted.  Keeping these bugs seperate allows the "target=" issue to be fixed
and closed, while allowing discussion to continue on the "window.open()" issue.
Blocks: 128632
*** Bug 131945 has been marked as a duplicate of this bug. ***
*** Bug 134129 has been marked as a duplicate of this bug. ***
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!
[adt3].  ->blaker to remove the pref until we can do this feature right.
Assignee: jaggernaut → blaker
Whiteboard: [adt3]
*** Bug 137425 has been marked as a duplicate of this bug. ***
Comment on attachment 79190 [details] [diff] [review]
patch: remove the pref for now

r=bryner
Attachment #79190 - Flags: review+
Attachment #79190 - Attachment description: patch → patch: remove the pref for now
Keywords: adt1.0.0
adt1.0.0+ on behalf of the adt.  Please check into the branch today and add
fixed1.0.0 in the keyword field.
Keywords: adt1.0.0 → adt1.0.0+
Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 138204 has been marked as a duplicate of this bug. ***
*** Bug 138288 has been marked as a duplicate of this bug. ***
*** Bug 138753 has been marked as a duplicate of this bug. ***
fixed (pref UI removed) on branch and trunk. back to jag, minusing.
Assignee: blaker → jaggernaut
Keywords: adt1.0.0+, nsbeta1+, useless-UI → adt1.0.0-, fixed1.0.0, nsbeta1-
Whiteboard: [adt3]
What happens if a user already has it set in their prefs.js file?  There's no
way to unset it without an editor after this patch goes in.  This could be a
real problem - we may need to also disable reading of the pref for 1.0 release.
Attachment #79190 - Flags: approval+
Comment on attachment 79190 [details] [diff] [review]
patch: remove the pref for now

oops, this didn't get the stamp. 
a=asa (on behalf of drivers) for checkin to the 1.0 branch

--Asa
Summary: Windows open in new window instead of tabs (target=<nonexsistant_frame>) → Windows open in new window instead of tabs (target=<nonexistant_frame>)
*** Bug 139333 has been marked as a duplicate of this bug. ***
*** Bug 141434 has been marked as a duplicate of this bug. ***
This bug should not be fixed without a base="" attribute check. Remember that
you can set something like this: <base href="http://www.mozilla.org"
target="_blank"> in order to open a new window. Also note that all framenames
should be checked when you are browsing frames.

I also agree that window.open or similar is something different. Why not use
some of the MultiZilla code? This code is located in contentAreaClick.js and I
will try to attach that file. Maybe someone likes to work on it because 35 votes
looks pretty much to me.
Attached file contentAreaClick.js (obsolete) — 
This file is taken from the MultiZilla project, just take a look how we solved
this problem.
Attached file new snap of code (obsolete) — 
Please insert/add this snap and give it a try. Let me know what you think of
it.
Attached patch diff -u (obsolete) — — Splinter Review 
Well, why not make a diff for it, so here it is.
That patch does not correctly handle existing named windows and targeted loads
to named windows...
I have this Bug in the bugzilla helper: "Search for your bug" opens a new window
despite I checked "windows opened by the web page" in the tabbed browsing section
"That patch does not correctly handle existing named windows and targeted loads
to named windows..."

Sure Boris, but isn't the whole concept for tabbed browsing to open tabs instead
of windows in the first place? All JavaScript calls to window.open should open a
new tab, and not a new window. This is however not functional at this moment so
we will have to struggle with this limitation, but that's another bug anyway.

In case you open two browser windows by hand, all calls to named windows should
open a tab in that browser window. So, this isn't a real issue if you ask me.
> Sure Boris, but isn't the whole concept for tabbed browsing to open tabs instead
> of windows in the first place?

Sure, but your patch breaks that, too.  If I have an anchor targeted at a named
window and I click it I get a new window (or with your patch a new tab).  If I
now click it again, the load occurs in the _same_ window as the first load but
with your patch it opens yet another new tab (since you have not introduced the
concept of named tabs, which is what I think your patch needs).
Attached patch new diff -u — — Splinter Review 
Improved patch, whitespaces removed (jag on irc) and target="foo" won't open
new tabs if it detects a tab by that name (see comment #71). Only one line is
changed in contentAreaClick.js this time. The major work is been done in
tabbrowser.xml 

note: _blank/blank and _new/new targets will open a new tab..
Attachment #81912 - Attachment is obsolete: true
Attachment #81915 - Attachment is obsolete: true
Attachment #81927 - Attachment is obsolete: true
Next thing is to change nsDocShell.cpp to prevent opening of new windows. It's
my guess that we need to add some lines here:
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#926  

mustMakeNewWindow should stay PR_FALSE and a new piece of code should open a new
tab when browser.tabs.opentabfor.windowopen is true.

Any other suggestions?
Yeah, do it the other way around, allow tabbrowser to hook into the process (in
some generic way) that intercepts such window open calls and redirects them to
tabs instead (which would allow us to simplify the js click logic too).
In case you like to try the latest patch (see comment #73) you must change this
line, I forgot to replace it:

if (getBrowser.mTabbedMode && linkNode.hasAttribute("target") ||
hasTarget("base", event)) {

with this:

if (pref && pref.getBoolPref("browser.tabs.opentabfor.windowopen") && 
    linkNode.hasAttribute("target") || hasTarget("base", event)) {

note for jag: I need more info (irc) before I can start.
I agree with <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=105547#c74">comment #74</a>. 
That would also fix it so that "netscape -remote openWindow()" (or whatever it
is) to pop up a page in a new tab.  Then I would feel  like Mozilla was properly
integrated with my work environment.
attachment 82119 [details] [diff] [review] seems to have a side effect: some frame targets do create a new
tab instead of being loaded in the targetted frame like they do without patch.

An example is http://www.rennradforum.de
Click "Textversion" and then click on "Dies & Das" in the upper left corner.
*** Bug 146191 has been marked as a duplicate of this bug. ***
*** Bug 150179 has been marked as a duplicate of this bug. ***
"attachment 82119 [details] [diff] [review] seems to have a side effect: some frame targets do create a new
tab instead of being loaded in the targetted frame like they do without patch."

That's already taken care of. The problem was related to nested framesets. We
only checked the first frameset and that was wrong.

Jag, I'm still waiting for a bit of help from you. How should I hook into what?
Fill me in please... 

Thanks,
/HJ
Look into how the content handler mechanism works. Basically we dispatch a "open
a (new) window for this protocol in this target with this url" request, and then
someone (right now that'd be the browser) accepts it and opens a new window or
reuses the window with that name. You could hook into that and make tabbrowser
intercept such requests and open them in named tabs instead.
*** Bug 153954 has been marked as a duplicate of this bug. ***
*** Bug 154129 has been marked as a duplicate of this bug. ***
Keywords: adt1.0.0-, fixed1.0.0, nsbeta1- → nsbeta1
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3]
I'm confused. Bug 138288 was added as a duplicate of this, but after reading
this bug more thoroughly, I think it's a different problem.

Bug 138288 (ENH) was to add a preference to force ALL new windows to open as
TABS. This sounds more like a bug regarding the "no window popups" option.
Should 138288 be re-opened, or is this, in fact, the same problem? (It doesn't
sound like the same problem, which irritates me to all hell that someone marked
138288 as a duplicate.)
Colin: It sounds like exactly the same problem to me. Both bugs are asking for
the ability to prevent the page from opening new windows, and to use tabs instead.
I suggested this for another similar bug, but maybe in regards to fixing this,
forget about popup windows and the like (since most users black unrequested
windows anyway) and focus on only intercepting valid "open in new window" links
that are clicked on by the user? You can always load these into new tabs
manually by middle clicking or control clicking, but unless you know the link is
"open in new window" BEFORE you click it you wouldn't think to do so. That's one
of my major irks with Mozilla right now, dealing with forcing popups/java
windows into new tabs should be a seperate bug somewhere, or more probably a
request and not a bug at all.
Blocks: 161466
*** Bug 163118 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 167817 has been marked as a duplicate of this bug. ***
*** Bug 168053 has been marked as a duplicate of this bug. ***
In case anyone looking for a quick workaround/fix (actually much more than that)
to the HTML side of this problem hasn't kept up with this bug's JavaScript
sister - bug 103843 - a comment on that thread -
http://bugzilla.mozilla.org/show_bug.cgi?id=103843#c68 -
provides a pointer to http://www.cc-net.or.jp/~piro/xul/_tabextensions.en.html
which is pretty much a Swiss-Army Chainsaw of tab hackery.

Comes with extensive, heck exhaustive, UI. Even allows you to reorder tabs by
drag 'n' drop.

The only thing I'm missing is the option to open targeted windows in the current
tab. My surprise (and irritation) is minimized if left-click always does this.
If I want to 'fork' my browsing I prefer to do so manually with middle-click
(ctrl-click &c).
user_pref("browser.block.target_new_window", true);

Putting that in your user.js file will cause *ALL* links to open in the current
tab. That way you can decide which links you'd like to open in new tabs yourself. 
Nice one. Works perfectly. Thanks, Josh.
Yup. Between that hidden pref and the tab extension addon I've been able to
workaround this pretty effectively. It'd still be nice to add it into Mozilla at
some point, but at least we can get this functionality now with a little legwork. 
*** Bug 170489 has been marked as a duplicate of this bug. ***
*** Bug 171502 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → pmac
*** Bug 176437 has been marked as a duplicate of this bug. ***
would this also make it so popups open as tabs?  (if so, there is a bug about
that as an RFE to out popup blocking story)
It's about <a href>'s only, Seth. There is a seperate bug (somewhere) that says
window.opens with NO width/height/etc args should be treated the same as <a
href=... target=_blank> for purposes of opening in a new tab vs window. There is
a SEPERATE bug (also somewhere) that deals with other js window.open's, where
it's debateable if we should ever open them in tabs, as that will very often
completely ruin the presentation.
http://multizilla.mozdev.org (tab hackery without the security issues)
*** Bug 180491 has been marked as a duplicate of this bug. ***
*** Bug 181185 has been marked as a duplicate of this bug. ***
------- Additional Comment #99 From Jeremy M. Dolan  2002-11-13 18:06 -------

" ... where it's debateable if we should ever open them in tabs, as that will
very often completely ruin the presentation."

If I check a box saying "Open ALL new pages in tabs instead of windows.", then
it is my prerogative to ruin the presentation.
I think the best solution is, that you add in the preference the following options:

open new window as:
-> open in the same window
-> open in a new tab
-> open a new window
-> ask each time, what to do
well, if we're going to offer to ask every time, then why not add:
-> surprise me
;-p
*** Bug 184412 has been marked as a duplicate of this bug. ***
*** Bug 185601 has been marked as a duplicate of this bug. ***
*** Bug 185616 has been marked as a duplicate of this bug. ***
*** Bug 185629 has been marked as a duplicate of this bug. ***
*** Bug 185651 has been marked as a duplicate of this bug. ***
*** Bug 185665 has been marked as a duplicate of this bug. ***
We should start marking erguv@hotmail.com bugs invalid instead of spamming this
with invalid dupes. Four from him today so far.
*** Bug 185849 has been marked as a duplicate of this bug. ***
With the followig line

user_pref("browser.block.target_new_window", true);

I run into trouble with Mozilla 1.3a and Linux:
When I start News/Mail or Addressbook from the browser window, the mozilla
process takes all memory and cputime and crashes after ca. 1 minute.

When I remove the user_pref-line, everthing is OK.
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
Sorry, this could be a problem of my maschine,
after a reboot everything is now OK.
*** Bug 186571 has been marked as a duplicate of this bug. ***
I haven’t seen any response on that good idea of preferences for opening new
windows.
*** Bug 190456 has been marked as a duplicate of this bug. ***
*** Bug 191315 has been marked as a duplicate of this bug. ***
*** Bug 191659 has been marked as a duplicate of this bug. ***
Whiteboard: [adt3] → [adt3][Hixie-P0]
*** Bug 194418 has been marked as a duplicate of this bug. ***
I agree that with those who say that there should be an option to set "open link
in new tab" as the default (or at least the first listed) action when one
right-clicks on link.
*** Bug 195705 has been marked as a duplicate of this bug. ***
*** Bug 196676 has been marked as a duplicate of this bug. ***
*** Bug 200516 has been marked as a duplicate of this bug. ***
*** Bug 201524 has been marked as a duplicate of this bug. ***
I agree with Comment #104 From Stefan Lüthje.  I would like this to be a
preference & was going to submit a bug report about it since the two reasons I
found mozilla intriguing were comments I read in my local paper & online about
the tabs feature and the pop up blocker.

I thought I was just missing the tab pref somehow, and can't quite understand
how this could be a central feature yet not the default.

I would like to have as possible defaults, order not particularly important, 
1) open link in new window
2) open link in new tab
3) open link in current window
4) ask each time {for Stefan, though I confess, I can't imagine choosing it}

and as an enhancement, and in deference to programmers I would like to add 'use
programmer/designer defaults' as an override if checked, but allow my preference
to be used if web page designer doesn't have a preference

I also think this should be an option either integrated or in its own preference
lists for bookmarks, etc. or perhaps simply in the sidebar as a whole.
<bugspam>
I hate to break this to you, but 'surprise me' is the current default behaviour.
A randomly selected link may either open in the current window/tab or may open
in a new window, with no easy way of determining in advance what the behavior
will be.

On the other hand, 'let me choose every time' is perfectly desirable behavior,
and is achieved by using the convention left click -> open in this window / tab,
right click -> Context Menu -> Open in a new window or open in a new tab (or
middle click -> Open in a new window or tab). That offers wonderful consistency,
but is currently only avaliable via a hidden pref. If that pref had UI (or
better still, a different default), the need for this bug to be fixed would
greatly be reduced.
</bugspam>
Please file new bugs for requests to add preferences. This bug is purely about
the existing pref not being followed for certain types of links (those that use
the HTML target attribute).
Target Milestone: mozilla1.0.1 → ---
To comment #128

>and as an enhancement, and in deference to programmers I would like to add 'use
>programmer/designer defaults' as an override if checked, but allow my preference
>to be used if web page designer doesn't have a preference

This would not be an enhancement but the current default behaviour. It would
come together with the behaviour described in #129.

So the list can be reduced to

"new window" links
- force new tab
- force current window
- default (-> new window / new tab if middle click ...)
*** Bug 207613 has been marked as a duplicate of this bug. ***
*** Bug 215244 has been marked as a duplicate of this bug. ***
*** Bug 215807 has been marked as a duplicate of this bug. ***
*** Bug 216015 has been marked as a duplicate of this bug. ***
Could be possible to override Link opening features by using key shortcuts?

I mean:
CTRL + Left mouse button click => Force to open link in new TAB
CTRL + Right mouse button click => Force to open link in new WINDOW

ALT button, may be also used for that task, but since it changes focus to menu,
ALT is not so much preferred as CTRL.

Sometimes, when I surf through some stupid pages opening new windows clicking on
link, I want to have specified in menu, if Mozilla should open new window or new tab
Misan Cijoml, Comment #137:
If I understand you correctly, there is such specific menu, where you can decide
if Mozilla should open link in a new window or new tab.

Press mouse right click on a link, and you will see menu items, like:
Open Link in New Window
Open Link in New Tab

Probably you just missed that feature.
I know about this feature - but I want never do it this way. Simply tell to
mozilla always open in a new tab like select in Properties. This you send me
works if I do that manually, but in normal click it respect new window specified
by html coder.
You know, you can also middle-click to open in a new tab in Firebird.  It's
configurable under Seamonkey, I believe.  Additionally, Ctrl+Left Click opens in
a new tab, and Shift-Left Click opens in a new window.  So, everything you want
is already available.  That's also not this bug.
*** Bug 217543 has been marked as a duplicate of this bug. ***
Comment #140 From Aaron Kaluszka:
Oh, great! True, CTRL+Left mouse click opens link in new tab!

However you are wrong when you say, SHIFT+Left mouse click opens link in new
window. It means Save Link Target as...
to Comment #139 From Misan Cijoml:
Yes, completely aggree with you. I feel the same way.
Personally I'm not interested, so I will not cry if this will not implemented,
However I accept that some users may want to open new windows in new tabs.

IMO, the default behaviour should be always to open in new window,
however it may be changeable in the preferences, to open in new tab.
In Navigator category, there should be an option with checkbox:
[ ] Open new windows in new tabs (when clicking a link would open new window)

By default it should be NOT turned on, but user may turn on, if it is needed.
Since Mozilla is able to do tabbed browsing, this option would be fair to have,
however should be not active until user doesn't specifically need it.

Webmaster33: Maybe you should read closer.  I said SHIFT+Left click works under
Firebird.  I'm pretty sure that it's somehow configurable under Seamonkey (but
could be wrong about that).  If that's not the case another bug should be opened
about that.
*** Bug 219010 has been marked as a duplicate of this bug. ***
*** Bug 219010 has been marked as a duplicate of this bug. ***
It seems to me that there should be several options as to what should happen if
you click on a link that wants to open a new window - 

1. Open a new window
2. Open in current window
3. Open in new tab
4. If it is javascript with parameters different from the current window (e.g.
height and width specifications, no menu, no toolbar, etc.) open in a new
window, otherwise open in a new tab. (This should be the default, IMO)
5. Ask user

I admit I haven't looked at mozilla source code, but it seems to me that it
would be fairly easy to implement; at the point where mozilla starts to open a
new window, check the setting, and the proceed accordingly. For example (using
pseudo code, since I don't know C):

PROCEDURE OpenWindow(href : String; name : String; specs : SpecType, ...) =
BEGIN
  CASE windowOpenOption OF
    1 : ; |
    2 : LoadNewPage(href);              (* Load the page in this window *)
        RETURN; |
    3 : OpenTab (href, name, ...) |     (* Load the page in a new tab *)
        RETURN; |
    4 : IF (Specs = self.Specs) OR (Specs = NIL)
          (* If the specs for the new window are the same or not specified *)
          THEN
            OpenTab(href, name, ...)
            RETURN;
        END; (* if *) |
    5 : userResponse = QueryUser ("Open in new Window or new Tab?");
        IF (userResponse = newTab)
          THEN
            OpenTab(href, name, ...)
            RETURN;
        END; (* if *) |
  END; (* case *)
  (* proceed to open new window.

This could only work, however, if the tabs are able to be named. The issue of
the named tabs, it seems to me, would be the most difficult part to implement.

If, for some reason, it isn't this simple, my apologies. It just seemed to me
that this should be a fairly straight-forward modification that was being way
overthought; when I've done that (more often than I like to admit), it usually
helps if someone else to ask what seems like an obvious question to get me back
to a simple solution. But since I don't know C and can't effectively analyze the
existing code, I may be totally off-base, but hopefully, my comments will help
someone come up with a simple, elegant solution.
Depends on: 103843
No longer depends on: 103843
*** Bug 219457 has been marked as a duplicate of this bug. ***
*** Bug 221051 has been marked as a duplicate of this bug. ***
*** Bug 224524 has been marked as a duplicate of this bug. ***
*** Bug 231254 has been marked as a duplicate of this bug. ***
I think the "press ctrl to open a link in a new tab" functionnality is somehow 
elegant enough... Yet, a functionnality that would open script windows in a 
tab by default would be greatly appreciated I suppose...
(In reply to comment #152)
> I think the "press ctrl to open a link in a new tab" functionnality is somehow 
> elegant enough... Yet, a functionnality that would open script windows in a 
> tab by default would be greatly appreciated I suppose...

That is elegant, and I think it would also be elegant to have a key that would
open a link (that specifies 
a new window) to open in the same window or tab. (And perhaps change the
contextual menu for such 
a link to say "Open Link in Current Window" instead of "…New Window" as in
Netscape products of old.)
I don't know if a link opens in a new window or not without checking it. Looking
at the properties or just clicking it.

The easiest thing for a browser should be to recognize the TARGET="_blank" as
"will open in a new window" and let the user configure the default behavior for
this.

All friendly popups use a different TARGET value.

That way you have both:
1.) Unwanted windows can go into a new tab, into the current tab, or ...
2.) Popups open in their own JavaScript-Windows.
*** Bug 235343 has been marked as a duplicate of this bug. ***
*** Bug 235604 has been marked as a duplicate of this bug. ***
Has there been any progress on this issue? It's been open for quite a while

To the people who are mentioning the middle click option etc - e.g. Comment
#140, you are obviously missing the point. We don't want to *force* the link to
open in a new tab (which is what middle-click does), but rather open it in a new
tab if it somehow requests a new window, in the existing window and tab if not.

I'm not sure if this belongs here, but I would also like to open a new tab
rather than a window when I request a browser "window" via a launcher that
executes remote call

openUrl(<url>, new-window)

In other words, I want to translate "new-window" into "new tab" there, too.

Well, actually, I would ideally like to get one browser window per workspace on
my Linux desktop, i.e. do the above mentioned translation if, and only if, the
mozilla window is visible on the current workspace.
Is that really what this bug is, Toralf? I hate pop-ups and such opening in a 
tab, actually. I am one of the many posters of duplicate bugs for this one, 
but now I don't think my bug is all that duplicate. I want a new tab when I 
click a link that opens in a new window, normally. but, if it is something 
like a pop-up initiated at onLoad, i dont want it in a tab. 
Calvin: I'm not sure I understand which part of my comment you are referring to.

I think this bug is about getting a tab instead of a window when clicking on a
link that requests a new target frame/window.

Some people seemed to be talking about functionality that will let yet you open
all link targets in new tabs - including the ones that would normally be
displayed in the same window. I think that's not relevant here.

The "remote" functionality I mentioned may of course be regarded as a separate
issue...

An I think there may be separate entries already for automatic popups in the
context of tabs.

Personally I'd be happy if there were a simple "always use tabs instead of
windows", option, though.
I think, the most people are happy with the undocumented feature (described at #30):

user_pref("browser.target_new_blocked", true);

It would be nice, if this option would be in the preference menue.
I think, the most people are happy with the undocumented feature (described at #30):

user_pref("browser.target_new_blocked", true);

It would be nice, if this option would be in the preference menue.
(In reply to comment #161)
> I think, the most people are happy with the undocumented feature (described at
#30):
> 
> user_pref("browser.target_new_blocked", true);
> 
> It would be nice, if this option would be in the preference menue.

According to bug 131155 comment 2, the pref got renamed to
browser.block.target_new_window, and it had UI. Unfortunately, according to bug
184425, the UI was disabled until bug 64560 is fixed, because the user
experience was that it didn't work for some links (in particular, JS windows.open).
Why is bugmail on this bug repeating the last 8 comments each time?
It's a Bugzilla bug. See bug 234159.
It happens evry tome someone adds or deletes himself to/from the CC list.

Therefore I'm leaving :-(
(In reply to comment #157)
> Well, actually, I would ideally like to get one browser window per workspace 
on
> my Linux desktop

Any my ideal would be Mozilla to leave us the choice of being "just like 
Opera", so open ALL windows in tabs... Actually it would have been great to 
give us such an option, perhaps in the browser preferences menu

Hum?
(In reply to comment #157)
> Well, actually, I would ideally like to get one browser window per workspace 
on
> my Linux desktop

Any my ideal would be Mozilla to leave us the choice of being "just like 
Opera", so open ALL windows in tabs... Actually it would have been great to 
give us such an option, perhaps in the browser preferences menu

Hum?
Blocks: 179501
No longer blocks: 179501
Blocks: 179501
*** Bug 238505 has been marked as a duplicate of this bug. ***
Severity: normal → enhancement
(In reply to comment #167)
> (In reply to comment #157)
> > Well, actually, I would ideally like to get one browser window per workspace 
> on
> > my Linux desktop
> 
> Any my ideal would be Mozilla to leave us the choice of being "just like 
> Opera", so open ALL windows in tabs... Actually it would have been great to 
> give us such an option, perhaps in the browser preferences menu
> 
> Hum?

That would require mozilla to me a multi-window environment (e.g. like
word/excel is). I think that would require the whole browser to change...
> > Any my ideal would be Mozilla to leave us the choice of being "just like 
> > Opera", so open ALL windows in tabs... Actually it would have been great to 
> > give us such an option, perhaps in the browser preferences menu
> > 
> > Hum?
> 
> That would require mozilla to me a multi-window environment (e.g. like
> word/excel is). I think that would require the whole browser to change...
That would not be right, IMO, but you may have misinterpreted the above comment
(unless I misunderstand yours ;-)). I don't think "just like Opera" refers to
all its different "sub window modes", just the way it opens tabs.

Differently put, I don't think anyone here is asking for changes in Mozilla's
basic GUI organisation and/or the way it displays windows and tabs - we just
want different ways to control which is used when.
(In reply to comment #170)
> > That would require mozilla to me a multi-window environment (e.g. like
> > word/excel is). I think that would require the whole browser to change...
> That would not be right, IMO, but you may have misinterpreted the above 
comment
> (unless I misunderstand yours ;-)). I don't think "just like Opera" refers to
> all its different "sub window modes", just the way it opens tabs.
> Differently put, I don't think anyone here is asking for changes in Mozilla's
> basic GUI organisation and/or the way it displays windows and tabs - we just
> want different ways to control which is used when.

When I've said "just like opera", it's actually not exactly just like Opera... 
What's be great is that we could choose to ALWAYS have sites that open new 
windows to open new tabs instead of windows. And perhaps NOTHING to open when 
we close Mozilla, since sites would be closed with the tabs.

That was my idea. Sorry I couldn't explain it the right way from the 
beginning :S
*** Bug 254020 has been marked as a duplicate of this bug. ***
*** Bug 254204 has been marked as a duplicate of this bug. ***
*** Bug 255586 has been marked as a duplicate of this bug. ***
Whiteboard: [adt3][Hixie-P0] → [adt3][Hixie-P0][parity-opera]
Blocks: 269942
*** Bug 278139 has been marked as a duplicate of this bug. ***
i have same problum, when i try creat new tab, sometimes it goes into tab, most
time is goes into new window, using firefox 1.0

im not sure as i stoped using 0.9 wich had alot bugs still i love firefox 1.0,
and this wont make me switch to opera or netscape wich are built from mozilla
Has this already been fixed? And if so, when and by whom? The test case now
gives me a lovely new tab rather than a horrible new window. Using Firefox build
20050208 on MacOSX
Summary: Windows open in new window instead of tabs (target=<nonexistant_frame>) → Windows open in new window instead of tabs (target=<nonexistant_frame>) (_blank)
*** Bug 287026 has been marked as a duplicate of this bug. ***
Can anyone show me a target="..." link that still opens a new window if the
according pref (browser.link.open_newwindow) is set? Both the backend in bug
172962 and the prefs UI in bug 161466 have been checked in now.
Otherwise I believe this can be marked fixed.
Using this preference makes bug 121377 much more noticable. Links that attempt
to reuse an existing window should reuse an existing tab with this preference
set. Bug 121377 causes those links to open a new tab instead of reuse an
existing one.
OK, but as that is filed as a different bug I can resolve this one. I think the
best way is to mark it as a dupe to the backend bug which implemented this.

*** This bug has been marked as a duplicate of 172962 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
No longer blocks: majorbugs
(In reply to comment #182)
> OK, but as that is filed as a different bug I can resolve this one. I think the
> best way is to mark it as a dupe to the backend bug which implemented this.
> 
> *** This bug has been marked as a duplicate of 172962 ***

Yeah, but that one is marked as fixed. Isn't this issue still open?
Bug 172962 was a firefox bug; this was a problem with seamonkey.
It was still an problem as of the last released 1.8 version of the suite.
Has anyone tried it in a built cvs version?

Is there yet a way to have target=[anything] ignored, but not break all
javascript window.opens? If not, this bug or another should still be open for
that. (Tested on 1.1 trunk).

Without the "Force links that open in new windows" pref checked, <a href=...
target=foo> will open in a new window. It's my browser. I'll tell it when to
open a plain link in a new window, damnit.

With the "Force links that open in new windows" pref checked, behavior is even
worse. Javascript onclick handlers that try to load a small, sized popup replace
the current page!

Where is the happy medium? One setting bothers users with absolutely pointless
new windows (there is no legitimate reason to use target=, as far as I know...
especially now with bfcache), and the other breaks tons of sites (window.open()
may be abused, but there ARE legitimate uses).
(In reply to comment #185)
> Is there yet a way to have target=[anything] ignored, but not break all
> javascript window.opens? If not, this bug or another should still be open for
> that. (Tested on 1.1 trunk).
> 
> Without the "Force links that open in new windows" pref checked, <a href=...
> target=foo> will open in a new window. It's my browser. I'll tell it when to
> open a plain link in a new window, damnit.
> 
> With the "Force links that open in new windows" pref checked, behavior is even
> worse. Javascript onclick handlers that try to load a small, sized popup replace
> the current page!
> 
> Where is the happy medium? One setting bothers users with absolutely pointless
> new windows (there is no legitimate reason to use target=, as far as I know...
> especially now with bfcache), and the other breaks tons of sites (window.open()
> may be abused, but there ARE legitimate uses).

hope this are all relevant settings. there is "just" a good ui missing.

browser.link.open_newwindow = 3
browser.link.open_newwindow.restriction = 2
browser.link.open_external = 3
browser.tabs.opentabfor.windowopen = false

this forces new targets to open in a new tab, but javascript window.open are
still new windows. (found that settings somewhere in the net, can't remember where)
(In reply to comment #186)
> hope this are all relevant settings. there is "just" a good ui missing.
 
Please go find somewhere else to discuss 1.7 branch. UI exists in the trunk,
with its own problems. See e.g. bug 293427

I guess I just don't get it.  I raised this issues maybe two years ago and it
went nowhere - but let me try again.

The right-click menu has a very serviceable and consistent "Open In New Tab"
command.  I use it all the time and wish it was the default without needing to
go through the right-click menu to get it done.

Now, I am not a programmer, but - There MUST exist some way to make whatever
that command does be selectable as the default if a user wants it.  If that was
possible, maybe at least some of us would be happy . .  

G. Beker
  
I guess I just don't get it.  I raised this issues maybe two years ago and it
went nowhere - but let me try again.

The right-click menu has a very serviceable and consistent "Open In New Tab"
command.  I use it all the time and wish it was the default without needing to
go through the right-click menu to get it done.

Now, I am not a programmer, but - There MUST exist some way to make whatever
that command does be selectable as the default if a user wants it.  If that was
possible, maybe at least some of us would be happy . .  

G. Beker
  
(In reply to comment #189)
> I guess I just don't get it.  I raised this issues maybe two years ago and it
> went nowhere - but let me try again.
> 
> The right-click menu has a very serviceable and consistent "Open In New Tab"
> command.  I use it all the time and wish it was the default without needing to
> go through the right-click menu to get it done.
> 
> Now, I am not a programmer, but - There MUST exist some way to make whatever
> that command does be selectable as the default if a user wants it.  If that was
> possible, maybe at least some of us would be happy . .  
> 
> G. Beker
>   

you can configure middle click so, that it dose the same like right-click ->
open in new tab. ;)

browser.tabs.opentabfor.middleclick = true
(In reply to comment #189)
> There MUST exist some way to make whatever
> that command does be selectable as the default if a user wants it.  If that was
> possible, maybe at least some of us would be happy . .  

Actually, there is a way. There exists an extension called "Tabbrowser
Preferences" which lets you define the behaviour of "target=" and javascript
open window commands via UI options, among other things. And of course this is
not the only extension to customize this behaviour, there are others as well.
Why is this bug closed?

The bug is still there and only because there are Plugins correcting the
mainprogram I don't see any reason why this bug should be marked as resolved.

I cannot understand why this bug is still ignored.

The fact nearly once a week, maybe more often, a new dublicate is postet and
added here shows how this bug annoyes the users.

Is there really a need to switch over to Microsofts behavior of just ignoring
the users?
I took a look on the dates and the last post of the bug 172962 is 2005-05-09 the
firefox 1.0.4 uses the Geckoengine Gecko/20050511 I know Gecko and the
preferences aren't the same, but I tought the dates are so close together, so
the bugfix should be included in 1.0.4.

My fault.

I downloaded the latest nightly build and noticed the new options. 

Sorry for the post.
No longer blocks: 128632
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: